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Abstract 

This  paper  presents  a  scheme  using  the  virtual  machine  concept  for 
creating: 

1)  An  environment  for  increasing  the  effectiveness  of  researchers  who 

must  use  analytical,  modeling  systems  and  have  complex  data  management  needs, 

2)  A  mechanism  for  multi-user  coordination  of  access  and  update  to  a 
central  data  base. 

3)  A  mechanism  for  creating  an  environment  where  several  different 
modeling  facilities  can  access  the  same  data  base. 

4)  A  mechanism  for  creating  an  environment  where  several  different  and 
potentially  incompatible  data  management  systems  can  all  be  accessed  by 
the  same  user  models  or  facilities. 

The  paper  investigates  and  formalizes  the  performance  implications 
of  this  scheme  specifically  directed  at  the  question  of  response  time  de- 
gradation as  a  function  of  number  of  virtual  machines,  of  locked  time  of 
the  data  base  machine,  and  of  query  rate  of  the  modeling  machine. 
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1.   Introduction 

Many  applications  demand  both  a  very   good  analytical  and  modeling  capa- 
bility, as  well  as  a  flexible  data  base  management  capability.  They  demand 
that  the  capability  be  on-line  and  interactive.  These  demands  are  particu- 
larly acute  in  information  systems  for  assisting  public  policy  decisions 
and  in  particular  we  have  found  in  the  area  of  energy  [Donovan:  1975; 
MacAvoy:  1974].  Such  systems  have  a  spectrum  of  users  ranging  from  the  non- 
technical to  the  researcher  to  the  computer  professional.  Each  grouping 
demands  a  different  level  of  detail  in  capabilities.  Further  such  systems  have: 

-  a  need  to  build  models  quickly. 

-  a  need  to  place  complex  protection  rights  un  data. 

-  a  need  to  validate  data. 

-  a  need  to  access  data  according  to  any  number  of  criterion. 

-  a  need  for  mechanisms  for  changing  the  system  to  meet  new 
demands  and  different  data  series  and  needs. 

-  a  need  to  handle  all  types  of  data. 

Modeling  systems  like  TROLL  [TROLL:  1972],  EPLAN  [Schober:  1974]"^aJd  TSP^/  ^''°'"''^ 
flexible  analytical  capabilities  such  as  sophisticated  statistical  methods, 
arithematic  operation,  plots,  graphs,  histograms  and  facilities  for  con- 
structing and  executing  mathematical  models.  All  of  these  have  some  short 


comings  but  the  most  serious  shortcoming  is  in  their  limited  data  manage- 
ment capabilities.  There  are  very   limited  facilities  for  protecting  data, 
storing  different  types  of  data,  changing  the  structure  of  data  or  tables 
in  the  system,  validating  data,  quering  data  by  specifying  different  con- 
ditions. Some  of  these  facilities  are  single  user  non  interactive  systems. 
None  allow  multiple  users  accessing  the  same  data  base. 

Corresponding  there  exist  data  management  systems  like  IMS,  DBDG, 
ENQUIRE,  TOTAL  which  provide  some  degree  of  data  manipulation  capabilities 
but  are  seriously  lacking  in  analytical  or  modeling  capabilities.  They 
also  lack  the  flexibility  in  use,  access,  and  protection  of  data  demanded 
by  some  applications  [jacoby;  1975].   They  do  however  have  considerably  more 
data  capability  than  the  modeling  systems  previously  mentioned.  This  lack  of 
flexibility  is  a  particularly  damaging  limitation  in  the  context  of  the 
certain  applications  for  several  reasons: 

1.  Since  unforseen  uses  and  needs  for  the  data  inevitably 
arise,  the  system  must  be  flexible  so  that  it  can  adapt 
to  these  changing  needs.  .  This  is  particularly  true  when 
providing  information  for  policy  decisions  in  so  volatile 
an  area  as  energy. 

2.  There  are  varying  constraints  imposed  by  changes  in  the 
quality,  availability,  and  protection  requirements  of 
data.  The  system  must  be  able  to  adjust  to  such  moving 
constraints. 

3.  The  system  must  be  able  to  accommodate  changing  needs  and 
constraints  at  reasonable  expenditures  of  cost  and  effort. 
Computer  systems  of  a  decade  or  two  ago  could  support  most 
current  applications,  but  in  many  cases,  only  at  a  high  cost. 


A  flexible  system  makes  it  possible  to  easily  experiment 

with  many  uses  of  the  data  at  modest  costs. 
We  have  developed  a  \/ery   flexible  data  management  system  called  TRANSAC 
[Donovan  &  Jacoby:  1974]  that  meets  these  criteria.  The  purpose  of  this  paper  is 
however  not  to  promote  any  one  modeling  system  or  data  management  system 
but  rather  to  present  a  scheme  whereby  the  good  features  of  any  system 
can  be  best  utilized. 

2.  Interfacing  modeling  facilities  and  data  base  facilities 

Let  us  explain  a  scheme  whereby  we  could  interface  a  modeling 
system  e.g.  TROLL,  to  a  data  base  system. 

For  conceptual  purposes, let  us  just  speak  of  two  separate  machines, 
one  at  l&le  which  is  running  TROLL  under  Yale's  operating  system  and  one  at 
M.I.T.  which  is  running  the  data  base  system  under  M.I.T. 's  operating  system. 

The  interface  scheme  would  be  whenever  the  Yale  machine  needs 
data,  it  would  request  a  courier  to  run  to  M.I.T.  and  get  the  data  out  of 
the  data  management  machine.  The  courier  would  then  bring  the  data  back  for 
the  modeling  machine. 

3.  Problems  with  interfacing 

Starting  with  the  scheme  of  using  two  independent  computer 
systems,  let  us  evolve  into  a  proposed  viable  scheme  which  we  advocate. 
1.  Many  modeling  facilities  are  single  user  non-interactive 
batch  oriented  (e.g.  TROLL  is  single  user,  IBM's  TSP  is 
batch  oriented).  A  multiuser  interactive  facility  is  de- 
sirable. 
-  Solution:  place  each  modeling  facility  on  a  separate 
machine. 
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Figure  i 
Multiple  Users  of  the  Same  Data  Base 


2.  We  would  like  more  than  one  use  (modeler)  to  be  able  to  access 
the  data  base  at  one  time. 

-  Solution:  Allow  many  machines  to  communicate  with  the  same 
data  base  machine  as  in  FigUre  1. 

3.  The  solution  to  2  creates  the  problem  of  coordination  of  updating 
the  single  data  base. 

-  Solution:  Only  one  modeling  system  will  be  serviced  by  the 
data  base  machine  at  one  time. 

4.  Not  every  user  will  want  the  same  modeling  facility;  some  will  want 
TSP;  others,  TROLL,  etc. 

-  Solution:  One  solution  is  to  require  all  users  to  convert  and 
all  existing  models  be  redone  in  one  modeling  language.  Another 
solution  is  to  run  a  courier  between  machines  that  have  different 
modeling  capability  on  them  and  the  single  data  base  machine  as 
in  Figure  1 . 

5.  Data  series  may  already  exist  in  several  and  incompatible  data 
base  management  systems.  How  can  a  user  access  these  data  series. 

-  Solution:  Interface  machines  that  have  different  data  base 
systems  as  in  Figure  2. 
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Figure  2 


6.  The  cost  of  many  separate  machines  is  high. 

Couriers  between  all  these  machines  are  slow  and  not  oractical. 
-  Solution:   Have  all  these  machines  run  on  the  same  machine, 

that  is,  have  one  machine  simulate  several  machines 

(virtual  machines).  On  some  of  these  virtual 

machines,  run  the  modeling  facilities;  on  others 

run  the  data  base  facilities;  on  one  run  the  general  data 

base  facility.  What  about  communication?  This 

will  be  discussed  in  Section  5. 

7.  What  about  performance? 

We  discuss  this  in  Section  6. 

4.  Description  of  Virtual  Machine  Concepts 

A  virtual  machine  may  be  defined  as  a  replica  of  a  real  computer 
system  simulated  by  a  combination  of  a  Virtual  Machine  Monitor  (VMM) 
software  program  and  appropriate  hardware  support.  (See  [Goldberg:  1973] 
for  a  more  precise  definition.)  For  example,  the  VM/370  (IBM  72)  system 
enables  a  single  IBM 


Systeni/370  to  appear  functionally  as  if  it  were  multiple  independent 
System/370' s  (i.e.,  multiple  "virtual  macliines").  Thus,  a  VMM  can  make 
one  computer  system  function  as  if  it  were  multiple  physically  isolated 
systems.  A  VMM  accomplishes  this  feat  by 

controlling  the  multiplexing  of  the  physical  hardware  resources  in  a  manner 
analogous  to  the  way  that  the  telephone  company  multiplexes  communications 
enabling  separate  and,  hopefully,  isolated  conversations  over  the  same 
physical  communications  link. 

By  restricting  itself  to  the  task  of  multiplexing  and  allocating  the 
physical  hardware,  the  VMM  presents  an  interface  that  appears  identical 
to  a  "bare  machine".  In  fact,  it  is  usually  desirable  to  load  a  user- 
oriented  operating  system  into  each  virtual  machine  to  provide  the  functions 
expected  of  modern  operating  systems,  such  as  Job  Control  Language,  command 
processors,  data  management  services,  and  language  processors.  Thus,  each 
virtual  machine  is  controlled  by  a  separate,  and  possibly  different,  opera- 
ting system.  The  feasibility  of  this  solution  has  been  demonstrated  on  the 
VM/370  system  and  the  earlier  CP-67  and  CP-40  systems 

In  addition  to  VM/370  and  its  predecessors,  several  other  operational 
virtual  machine  systems  have  been  developed,  such  as  the  DOS/VM  of  PRIME 
Computer,  Inc.  [PRIME:  1974],  the  virtual  machine  capability  provided  under 
the  Michigan  Terminal  System  (MTS)  [Morrison:  1973],  and  a  virtual  machine 
system  for  a  modified  PDP-11/45  used  by  UCLA  for  data  security  studies 
[Popek  &  Kline:  1974]. 


The  VMM  concept,  once  unclerstood,  is  quite  simple  and  logical.  Unfor- 
tuntely,  it  is  sufficiently  different  from  most  conventional  operating  systems 
that  many  people  have  difficulty  in  understanding  the  concept.  The  papers 
[Buzen:  1973,  Goldberg:  1973,  Hogg:  1973,  Madnick:  1969,  Parmellee:  1972,  and 
Madnick  &  Donovan:  1974]  give  additional  insight. 

At  first  the  idea  of  replicating  the  bare  machine  interface  may  seem 

foolish  since  you  end  up  back  where  you  started.  The  key  difference  is 
VM/370  produces  the  effect  of  multiple  bare  machines.  In  this  way  each 

user  appears  to  have  his  own  370  computer.  Thus,  each  user  can  select  the 

operating  system  (e.g.  OS/360  DOS,  etc.)  of  his  choice  to  run  on  his 
"private"  computer. 

How  does  VM/370  produce  this  feat?  How  do  the  users  of  VM/370  communi- 
cate with  it?  Programs  running  under  VM/370,  usually  operating  systems 
physically  execute  in  problem  state  but  can  behave  as  if  they  were  in 
supervisor  state.  When  they  issue  a  privileged  instruction,  such  as 
START  I/O  or  SET  STORAGE  KEY,  an  interrupt  occurs 'and  control  transfers  to 
VM/370.  The  interrupt  is  handled  in  such  a  way  that  the  program  thinks 
that  the  privileged  instruction  was  actually  executed.  Thus,  these  privi- 
leged instruction  interrupts  are  the  subtle  interfaces  between  users  and 
VM/370. 

Additional  advantages  of  VM  are  outlined  in  [Buzen:  1973]  and 
[Madnick  &  Donovan:  1974,  1975]. 
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5.  Use  of  VM  in  Information  Systems 

As  was  discussed  in  Section  4,  having  multiple  machines  gives  the 
effect  of  having  multiuser  modeling  facilities  which  can  access  data  stored 
in  several  different  data  bases.  Proposed  communication  between  all  these 
was  via  courier.  Another  possibility  and  the  scheme  we  advocate  is  to 
simulate  several  different  machines  on  one  machine  using  the  VM  concept. 
This  section  discusses  the  implications  and  mechanics  of  this  possibility. 

Combining  the  solutions  of  the  previous  section,  we  could,  for 
example,  create  a  configuration  of  VM's  whose  architecture  could  be  depicted 
as  in  Figure  2,  where  each  box  denotes  a  virtual  machine. 


11 


5.1  Communications  between  VM's 

Configuring  several  VM's  on  one  real  machine  as  in  Figure  2  allows 
several  modeling  systems  to  access  data  from  a  single  data  base  management 
system.  When  a  modeling  facility  issues  a  request  for  data,  that  request 
is  output  on  a  virtual  card  punch  and  sent  to  the  data  management  machine's 
virtual  card  reader.  The  data  management  machine  reads  the  request,  selects 
the  data,  and  transfers  the  data  back  to  the  modeling  facility  via  the  trans- 
fer of  data  from  the  data  management  virtual  punch  to  the  modeling  facility's 
virtual  reader. 

Note  that  no  (physical)  cards  are  involved  in  this  process.  The 
"card  files"  which  are  punched  and  read,  are  in  fact  stored  on  (physical)  disks 
for  the  transfer. 

The  amount  of  reprogramming  and  design  involved  in  modifying  the 

data  base  management  system  DBMS  to  accept  requests  and  output  data  to  its 

complexity 
virtual  card  devices  is  relatively  small,  compared  to  the  amount  of  work  and/ 

that  would  be  involved  in  rewriting  the  modeling  system  to  include  a  facility 

for  data  handling,  for  multiusers,  for  interactive  editing,  for  synchronization 

of  data  base  access  and  updating. 

Since  all  modeling  facilities  have  mechanisms  to  store  data  in 
files  and  facilities  to  operate  on  this  data,  the  modification  to  a  modeling 
system  under  the  VM  scheme  consists  of  adding  three  commands: 

-  adding  a  command  to  convert  the  data  outputted  from  the  DBMS 

into  the  format  that  the  modeling  facility  uses. 

By  adding  two  more  commands,  a  modeling  system  which  has  very  poor 
data  management  capabilities  can  appear  to  a  user  as  if  he  had  a  very  powerful 
facility  for  storing,  quering,  updating,  and  manipulating  data. 
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-  adding  a  command  that  has  as  possible  arguments  the  commands 

of  the  data  base  system.  The  modeling  system  "passes"  the  command 
on  to  the  data  base  machine  via  virtual  cards. 

-  adding  a  command  which  prints    data  passed  back  to  the  modeling 
facility. 

This  scheme  will  also  work  with  most  data  base  systems,  as  most  of  them 
have  (or  it  is  easy  to  add) 

a  mechanism  for  reading  request  in  from  files  or  cards  and  outputting  results 
to  cards  or  files. 

^•^   Multiuser  Coordination 

The  basic  problem  with  having  multiple  users  of  the  same  data  base 
is  how  to  prevent  race  conditions  and  uncertainties  resulting  from  several 
users  accessing  and  updating  the  same  data  base.  A  mechanism  we  advocate 
is  to  have  the  data  base  virtual  machine  only  allow  one  user  to  access 
or  update  its  VM  at  one  time.  Thus,  whenever  the  data  base  virtual  machine 
is  processing  a  request,  it  queues  all  other  requests.  The  queue  is 
serviced  on  a  FIFO  basis. 

The  performance  implications  of  this  approach  have  not  been  experi- 
mentally tested.  A  mathematical  analysis  of  the  performance  is  presented 
in  Section  6. 

5  .3  Multiple  Modeling  Interfaces 

Adding  the  commands  outlined  in  the  previous  section  to  other 
modeling  facilities  and  running  each  of  these  different  modeling  facilities  in 
a  separate  VM  allows  several  different  modeling  facilities  to  communicate  with 
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the  same  data  base.  Thus,  incompatible  systems,  such  as  TROLL  and  EPLAN, 
can  work  from  the  same  data  base. 

5.4   Incompatible  Data  Management  System 

Let  us  suppose  that  there  is  a  need  to  create  a  DBMS  that  uses  data 
from  several  data  bases,  each  of  which  is  on  an  incompatible  data  base 
system.  We  reject  copying  all  data  bases  into  one  data  base  system  because, 
for  example,  the  existing  DB  systems  may  be  specialized  to  keep  the  data  up 
to  date.  Thus,  how  can  we  treat  these  four  physically  separate  data  bases 
as  one  logical  unit? 

A  solution  to  this  problem  is  also  shown  in  Figure  2,  where  we  could  configure 
three  virtual  machines  to  allow  the  mutually  incompatible  data  base  manage- 
ment systems  to  run  on  the  same  physical  computer.  We  then  implement  another 
VM  to  act  as  an  interface,  analyzing  the  data  query  and  funnel ing  it  to  the 
appropriate  DBMS  (via  virtual  card  files).  All  of  these  mechanisms  can  be 
made  invisible  to  the  user,  who  can  use  the  system  as  though  he  had  all  the 
data  in  one  "virtual"  data  base. 

Note  the  "user"  in  this  sense  can  be  a  modeling  facility  or  a  person, 
i.e.,  a  user  here  is  anything  that  makes  a  data  request. 

5.5.   A  Practical  Example 

We  have  configured  a  cluster  of  VM  as  in  Figure  2  to  produce  a  total 
system  for  research  in  energy  policy  analysis.  We  call  the  system  GMIS 
(General  Management  Information  System).  Figure  3  depicts  the  ultimate 
GMIS  system  [Donovan  et  al :  1975],    where  across  the  top  several  modeling 
or  analytical  systems  are  depicted  as  running  on  separate  virtual  machines. 
Note  that  each  of  these  analytical  systems  may  be  running  under  a  different 
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operating  system,  e.g.,  TSP  running  under  MVT,  TROLL  running  under  CP/CMS, 
EPLAN  running  under  VSZ.  TRANSACT  [Donovan  and  Jacoby:  1975]  is  a  data  base 
system  based  on  the  relational  model  of  data  [Codd:  1970]  and  uses  some  IBM 
software  [Chamberlain:  1974].  TRANSACT  is  implemented  in  a  hierarchical  fashion 
[Dijkstra:  1968,  Madnick:  1970,  Donovan:  1972],  and  as  such  it  is  a  very 
flexible  and  powerful  data  management  system.  Across  the  bottom  of 
Figure  3  are  depicted  several  data  base  systems,  each  of  which  may  be 
incompatible  and  running  under  different  operating  systems. 

Note  that  in  this  paper,  independently  of  any  one  data  base  system,  we 
are  advocating  the  use  of  VM  to  produce  an  environment  where  multiple  analy- 
tical machines  can  be  used  on  the  same  facility  and  these  analytical  systems 
have  access  to  data  base  systems. 
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5-  Performance 

Not  only  does  the  VM  approach  solve  all  the  problems  of  Section  3 
but  it  also  has  the  following  cost  benefits: 

-  no  conversion  cost  in  bringing  up  existing  models  as  long  as  they 
run  on  an  IBM  machine  (independent  of  lanuguage  or  operating  system). 

-  no  retraining  cost  involved  as  programmer's  may  use  whatever 
system  they  are  familiar  with. 

-  little  cost  involved  in  implementing  the  simple  interfaces. 
What  is  the  possible  disadvantage  -  performance  ,  which  is 

reflected  in  additional  overhead  costs:  For  example,  the  following 
questions  arise: 

-  How  many  users  (modeling  machines)  can  use  the  same  data  base 
machine?  That  is,  what  is  the  degradation  of  response  time  as  a 
function  of  the  number  of  modelers? 

-  What  is  the  degradation  cost  due  to  the  synchronization  mechanism? 

-  What  is  the  degradation  cost  due  to  VM? 
We  have  separated  the  two  performance  costs: 

(1)  due  to  lock  out  synchronization  mechanisms  and 

(2)  due  to  VM  overhead. 

The  approach  to  answering  these  questions  we  take  here  is  an  analytical 
one.  We  will  first  analyze  the  performance  issues  of  lock  out  by  configuring 
a  system  of  separate  real  machines.  We  then  analyze  the  cost  of  VM  by 
configuring   the  separate  real  machines  or  as  virtual  machines  on  one 

real  machine.  Other  approaches  to  gain  other  factors  of  performance  in 
VM  are  discussed  in  [Hatfield:  1972,  Goldberg:  197^]. 
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7.1  Analysis  as  Separate  Machines  (performance  degradation  due  to  lock 

out) 

Assuming  a  configuration  as  in  figure  i,  where  several  modeling  facilities 
each  running  on  a  separate  real  machine  are  accessing  and  updating  a  data 
base  which  is  managed  by  a  data  base  management  system  running  on  its  sepa- 
rate real  machine,  what  is  the  degradation  of  performance  with  each 
additional  user?  What  is  it  as  a  function  of  the  length  of  time  the  DB 
machine  takes  to  process  a  request? 

An  access  or  update  to  the  DB  machine  may  be  initiated  either  by  a 
query  from  a  person  which  would  be  passed  on  by  the  modeling  machine  or 
by  a  model  executing  on  the  modeling  machine. 

In  either  case,  the  DB  machine  while  processing  a  request  locks  out 
(queues  )  all  other  requests.  Let  us  write  a  function  that  specifies  total 
response  time  of  a  model. 


total    overhead   model    request  and  wait 


where 


total 


total  response  time  of  a  task,  (e.g.,  a  model)  that 
is,  total  time  from  the  start  of  execution  of  a 
model  to  the  answer. 


overhead 


T 


model 


amount  of  CPU  time  spent  executing  instructions 
in  the  operating  system  of  the  modeling  machine. 

amount  of  CPU  time  executing  the  instruction 
associated  with  the  model. 


request  and  wait  =  time  modeling  machine  waits  for  request 

to  be  processed  plus  time  spent  waiting  for  request 
to  be  serviced  by  ths  DB  machine. 
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What  one  would  want  to  know  is  what  happens  to  T  .  ,  as  a  function 
of  the  number  of  users.  That  is,  how  many  users  can  we  tolerate  on  the 
system. 

Assume  that: 

(1)  a  configuration  of  separate  real  machines  as  in  figure  l. 

(2)  the  time  spent  in  executing  the  model  in  a  modeling  machine 
before  issuing  a  request  for  data  to  the  DB  machine  is  negative 
exponentially  distributed  with  mean  1/A 

(3)  the  time  for  the  DB  machine  to  serve  a  request  is  negative 
exponentially  distributed  with  mean  l/y 

(4)  the  order  of  service  at  the  DB  machine  is  FIFO 

(5)  the  number  of  modeling  machines  is  m 

We  can  formualte  the  probelm  as  a  machine-repairman  model  [Satty:  1961] 
as  shown  in  Figure  4.  The  steady  state  equations  are: 

mAP^  =  yPi  -| 

[  for  0  <  i  <  m 
[  (m-i)  A+y]  P.  =  (m-i+1)  A  P._^  +  yP.^^ 


y  P  =  AP  , 
m     m-1 


Where  P.  is  the  steady-state  probability  that  there  are  i  modeling 
machines  waiting  and  being  served. 
The  solution  is: 
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P.  =  P  (^  )^    (  "^  )  i 

=  P^  (  -  )^       m: 
°  ^  "■  (m-i): 

where  i  =  1 ,  • • • ,  m 

where, 

m    \  -1 


°   li=o  Po  / 

Z   (  A/y  )  ^  (i")  i:  j 


Z        (  A/y  )  ^  m:   A  "^ 
i=o         (m-i ): 


The  average  response  time  for  a  request  to  DB  machine  as  derived  by 

[Little:  1961]  is: 

m 

R  =    I        i  Pi 

i  =  i 


^T^) 


Figure  5  illustrates  the  wait  and  process  time  for  a  single  request 
as  a  function  of  modeling  machines.  For  example,  with  —  =  1>  five  users  on 
the  system  degrades  the  response  time  of  each  user  by  a  factor  of  four.  With 
a  -  ratio  of  less  than  .1  there  is  almost  no  degradation  of  response  until 
a  large  number  of  users  are  using  the  system 

Note:  In  all  the  remaining  graphs  y  is  set  at  a  constant  value  of  1.0, 
and  N  (number  of  dcUa  requests)  is  a  constant  10.  The  values  of  Tgygp^ggj 
is  a  constant  equal  to  1.0. 


Figure  4 
Model  of  Figure  l 
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Figure  5 
Response  Time  for  a  Single  Request 
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Assume  that  the  average  number  of  data  requests  to  DB  machine  in 
running  a  model  in  a  modeling  machine  is  N.  The  data  base  is  locked  only 
while  a  request  is  being  processed.  We  are  assuming  there  is  no  reason  to 
lock  the  data  base  for  the  whole  period  while  a  model  is  running.  The 
situation  where  a  data  base  must  be  locked  for  the  entire  period  of  execu- 
tion (e.g.,  a  possible  danger  that  other  modeling  machines  will  change 
sensitive  data  in  between  requests)  requires  another  anlaysis. 

The  total  time  waiting  for  data  from  the  Data  Base  machine  is: 

"''  wait  for  data  =  1^  *  ^ 

The  average  time  spent  in  executing  a  model  in  a  modeling  machine  is 
a  constant: 

T      =  N  .  (1/X) 
model 

The  overhead  of  the  operating  system  of  one  modeling  machine  is  fixed 
and  is  equal  to  a  constant  Tq^^^^^^^.   The  total  time  to  execute  a  model 
in  the  modeling  machine  is: 

total    overfiead    model    wait- for- data 
and  is  plotted  in  Figure  6. 
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Figure  6 
Total  Response  Time 
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5.2  Analysis  if  All  Machines  are  VM's  on  One  Real  Machine 

If  all  machines  are  run  as  virtual  machines  on  one  real  machine,  what  is  the 
additional  degradation  of  response  time? 

In  the  VM  configuration  actually  the  real  machine  spends  a  small  portion 
of  its  time  on  each  VM.  As  the  number  of  VM's  increase,  then  each  VM  will 
get  less  of  the  real  CPU's  time  thus  further  increasing  the  elapse  time  between 
the  start  of  a  model  and  the  production  of  the  answer. 

The  analysis  is  further  complicated  by  the  fact  that  as  some  VM's  become 
locked  then  others  get  more  of  the  real  CPU's  time,  therefore,  they  generate 
requests  faster.  However,  the  DB  VM  gets  more  of  the  CPU's  time  thereby 

processing  requests  faster.  For  example,  if  there  are  ten  virtual  machines, 
each  one  receives  one- tenth  6f   the  real  CPU.  However,  if  seven  of  the  ten 
are  in  a  locked  state,  then  the  remaining  three  receive  one-third  of  the 
CPU.  Thus,  these  three  run  (in  real  time)  faster  than  they  did  when  ten 
were  running.  The  following  is  an  analysis  of  VM's  performance  for  the  use 
outlined  in  this  paper. 

We  have  assumed  that  the  virtual  speeds  of  VM's  are  constant  and  equal.  However 
when  some  VM's  are  blocked  (i.e.,  waiting  for  data  from  the  DB  VM),  the  remaining 
VM's  (including  DB  VM)  are  allocated  a  larger  share  of  CPU  processing  power  and 

became  faster  in  real  time.  We  assume  that  each  unblocked  VM  receives  the 
same  amount  of  CPU  processing  power  and  at  the  initial  state  m  machines  are 
running  (i.e.,  the  data  base  machine  is  stopped  if  no  modeling  machines  are 
making  requests).   'X'is  request  rate  of  each  modeling  VM  when  there  are 
m  VM's  running,  'p  '   is  the  service.  r<,t.P_At  which  the  data  base  virtual 
machine  is  running  when  there  are  m-1  modeling  VM  and  one  data  base  VM 
running.  Thus,  we  may  write  the  relations: 
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m 
m-i+1  ^ 


Ao  =  A 


^- 


m    X 


m-1+1 


(i  =  1,  2,  ...,m) 


(i  =  1,  2,  ...,m) 


where  i  (i  =  0.1,..., m)  is  the  number  of  modeling  VM's  being  blocked. 
Using  a  birth/death  process  model  [Drake:  1967],  the  state  transition 
diagram  is  shown  in  Figure  7. 


mXt 


(m-l)A, 


(m-2)X: 


r 


y- 


Figure  7 
State  Transition  of  Multi-VM  Model 
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From  this  model,  the  steady  state  equations  are  [Drake  1967] 
m  Xq  Pg  =  y^  P^ 

[  (m-i)  X.  +  y .  ]  P.  =  (m-i+1)  X._^  +  y.^^  P.+^ 


^m  m  ~  m-1  m-1 


i<m 


The  solution  of  the  above  set  of  equations  is: 
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,     J  A    (m-1)! 
i  \ H  /  Tm-i)! 


(m-i+1)  P< 


(i  =  1,  2,  3,...,m) 


where 


Po  = 


1=1 


-» 


Mr  <"-^" 


-1 


The  average  response  time  for  a  request  to  the  DB  VM  in  this  VM  con- 
figuration is  obtained  by  generalizing  the  analysis  [Little:  1961]  to  this 
situation  where  there  is  queue  dependency. 


m 

E   iP 
r'  =  i=l 


m 


1=1 


'i'  1 


Figure  8  illustrates  the  response  time  of  a  single  request  as  a  function 
of  the  number  of  modeling  VM's. 

Similar  to  equation  of  section  6.1, 
T' 


overhead    overhead 
N.R. 


wait-for-data 
T'   .  1  is  calculated  similarly  to  the  way  T^Q^jg]  was  calculated  in 


model 

section  6.1.  That  is,  T'^^^^^  =  N 

Thus  we  take  a  weighted  sum  and  get  the  following.  (Note  that  if 


However,  the  X's  vary. 


A.  are  constant,  this  reduces  to  the  T^Q^jg] 


of  section  6.1 . 


"^'model  "  ^• 


i-o   i  [ml 

im-i\ 


m-1 
I       P 
i=o 


T '       =  T  '  +  T '       +  T  ' 

total     overhead    model    wait-for-data 


Fiqure  9  illustrates  the  total  time  to  execute  a  model  as  a  function  of  the 
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Figure  8 
Response  Time  of  a  Single  Request  in  a  VM  Configuration 
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Figure  9 
Total  Elapsed  Time  in  a  VM  Configuration 
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-J       Techniques  for  Reducing  Synchronization  Overhead 

The  synchronization  of  the  access  and  updates  to  the  DB  Virtual  Machine 
is  accomplished  by  what  we  call  a  spin  lock.  That  is,  if  the  modeling  VM 
encounters  a  "locked"  DB  VM,  then  it  must  wait  (in  a  queue);  until  the  DB  VM 

is  unlocked,  the  modeling  machine  cannot  do  anything  else. 

we  have  seen,  has  an  adverse  effect  upon  system 
The  use  of  locks  where  the  VM's  must  wait  if  encnunterinn  a  lock,  as  / 

performance.  Several  techniques  may  be  used  to  reduce  this  synchronization 

overhead,  and  the  relative  merits  of  each  must  be  weighed. 

One  approach  is  to  use  a  single  lock  (as  we  have  done)  to  cover  all  shared 
in  the  single  DB  VM. 
data  bases/  The  alternative  is  to  identify  all  separate  data  bases  carefully 

and  associate  a  separate  lock  with  each. 

There  are  many  factors  to  be  considered  in  choosing  between  a  precise  lock 
approach  (i.e.,  a  large  number  of  separate  locks)  and  an  overall  lock  approach 
(i.e.,  one  lock  for  all  data  bases).  In  the  precise  approach,  considerable 
overhead  is  incurred  in  setting  and  resetting  locks,  even  though  the  parti- 
cular data  base  is  not  needed  by  any  other  VM.  This  multitude  of  locks  also 
greatly  complicates  debugging. 

In  the  overall  lock  approach  (also  called  brute  force),  the  lock  may  be  on 
for  long  periods  of  time  (up  to  50  percent  or  more).  This  greatly  increases 
the  likelihood  of  software  lock-out  and  the  resulting  slow  response  time. 

8,  Techniques  for  Reducing  Effect  of  VM  on  Response  Time 

The  basic  reason  for  the  degradation  of  performance  due  to  VM  is  the 
fact  that  one  real  machine  is  being  used  to  simulate  several  VM's.  That  is, 
one  real  CPU  spends  a  little  time  on  VM  #1,  then  on  VM  #2,  then  on  VM  #3 
and  so  forth.  Thus,  each  VM  only  gets  a  fraction  of  real  CPU  time. 
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One  method  of  increasing  the  amount  of  real  CPU  each  VM  gets  is  to 
increase  the  number  of  real  CPU's.  That  is,  use  a  multiprocessor  configuration. 
Note  all  processors  are  executing  instructions  in  the  same  memory. 

The  trade  off  is,         the  cost  of  the  extra  processors  and  their 
real  effect.  That  is,  each  additional  processor  incurs  some  overhead  and 
introduces  a  lower  level  set  of  locking  problems.  The  lower  level  locking 
problem  arises  from  having  to  lock  "system"  data  bases  whose  access  and 
updating  must  be  synchronized  (e.g.,  the  system  table  which  keeps  track  of 
what  process  the  processor  should  be  assigned  to). 

Treating  each  VM  as  corresponding  to  a  separate  process,  we  may  perform 

a  similar  analysis  [Madnick  and  Donovan:  1975]  to  determine  the  effectiveness 
of  additional  CPU's. 
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9.  Summary 

Running  individual  modeling  facilities  on  separate  machines  all  interfaced 
to  a  single  database  machine  creates  a  total  facility  that  is  multiuser, 
interactive,   suited  to  individual  tastes  and  provides  access  to  a  single  common 
data  base.  Simulating  all  these  machines  as  virtual  machines  on  one  real  machine 
provides  a  mechanism  for  ■'^ast  and  inexpensive  communication  between  machines. 
Multiple  use  of  a  single  database  creates  the  problem  of  synchronization 
of  access  and  updates  to  that  database.  The  spin  lock  provides  a  synchronization 
mechanism,  however,  at  a  performance  cost  in  increased  delays  in  response 
time.  Figure  10  dotted  curves  give  these  times  assuming  separate  real 
machines. 

The  performance  implications  of  the  use  of  VM  can  be  seen  in  Figure  10, 
that  is,  the  degradation  because  of  VM     becomes  significant  with  large 
numbers  of  VM's. 

Response  time  degradation  due  to  a  lock  can  be  improved  by  partitioning 
the  data  base  and  using  more  than  one  lock.  Degradation  due  to  overhead 
associated  with  VM  (one  real  processor  simulating  many)  may  be  improved 
by  adding  more  processors. 
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Figure  10 
Comparison  of  Total  Elapsed  Times  for  a  VM  and  a  non-VM  Configuration 
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